@petschki thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

simply put: I am in LOVE. big style! <3

@petschki I like(for desktop)! What about mobile?

As you see in the screencast, on mobile the offcanvas behavior is used. This behaves like the "expanded" desktop toolbar but hideable offcanvas. The behavior is basically the same like in Plone 5 mobile toolbar only on the left side instead on the right side (which I didn't really understood why this moved there)

What about top bar? It should not change, already had the dropdowns. Nice job!

@yurj topbar stays untouched ... even more it's much simpler because for topbar I (more or less) only remove the class dropend on submenu items ...

Wow! I must admit I was a bit self-conscious about voicing my personal opinion so loud about this on the podcast, but it is a big UX issue to have menu items that move their position dynamically.

It's a variation on what Microsoft got a lot of complaints about when in a previous Office version they made the submenu's also dynamic by removing options that were invalid in the current context, instead of greying them out and keeping al menu items' position stable.

The underlying process here is that you develop a mental muscle memory where you know that when you click open a menu the submenu item is always relatively at that position from where you activated the menu 'header'.

What happened to me as well a few times is that when i clicked open the menu and the submenu shifted in under my mouse position but I accidentally double clicked I activated the submenu item. Thiinking about this, like color blindness this is also an accessibility issue for people with motoric handicaps where they accidentally double click.

Wow! I must admit I was a bit self-conscious about voicing my personal opinion so loud about this on the podcast, but it is a big UX issue to have menu items that move their position dynamically.

It's a variation on what Microsoft got a lot of complaints about when in a previous Office version they made the submenu's also dynamic by removing options that were invalid in the current context, instead of greying them out and keeping al menu items' position stable.

The underlying process here is that you develop a mental muscle memory where you know that when you click open a menu the submenu item is always relatively at that position from where you activated the menu 'header'.

I like that and it made me think about roles/users on context, as i don't see the need to display icons for admin tools not meant for all other roles/users. Staying consistent per role or even per user (thinking about "most often used content types") is an interesting approach.

what about sub items - like displaying all content-types, actions, workflows in their menus but disabling those not allowed/available in the current context?

but not on this pr as it is an exciting and whole new story to think about.